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This document defines an architecture for implementing scalable 
service differentiation in the Internet. This architecture achieves 
scalability by aggregating traffic classification state which is 
conveyed by means of IP-layer packet marking using the DS field 
[DSFIELD] . Packets are classified and marked to receive a particular 
per-hop forwarding behavior on nodes along their path. Sophisticated 
classification, marking, policing, and shaping operations need only 
be implemented at network boundaries or hosts. Network resources are 
allocated to traffic streams by service provisioning policies which 
govern how traffic is marked and conditioned upon entry to a 
differentiated services-capable network, and how that traffic is 
forwarded within that network. A wide variety of services can be 
implemented on top of. these building blocks. 
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1. introduction 

1.1 overview . 

This document defines an architecture for implementing scalable 
service differentiation in the internet. A "Service" defines some 
significant characteri sties" of packet transmission in one direction, 
across a set of one or more paths within a network. These 
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characteristics may be specified in quantitative or statistical terms 



heterogeneous application requirements and user expectations, and to 
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characteristics may be specified in quantitative or statistical t< 
of throughput, delay, jitter, and/or loss, or may otherwise be 
specified in terms of some relative priority of access to network 
resources. Service differentiation is desired to accommodate 
heterogeneous application requirements and user expectations, and 
permit differentiated pricing of Internet service. 

This architecture is composed of a number of functional elements 
implemented in network nodes, including a small set of per-hop 
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forwarding behaviors, packet classification functions, ^andtratric 
conditioning functions including metering marking, shaping, and 
policing. This architecture achieves scalability by implement! no 
complex classification and conditioning functions only « network 
boundary nodes, and by applying .per-hop behaviors to aggregates of 
traffic which have been appropriately marked using the DS tie 10 in 
the IPv4 or IPv6 headers {DSFIELD] . Per-hop behaviors are defined to 
pe e rmi? V a reasonably granular means of allocating buffer and bandwidth 
resources at each node among competing traffic streams. Per 
application flow or per-customer forwarding state need not be 
maintained within the core of the network. A distinction is 
maintained between: 

o the service provided to a traffic aggregate, 

o the conditioning functions and per-hop behaviors used to realize 
services, 

o the.DS field value (DS codepoint) used to mark packets, to select a 
per-hop behavior, and 

o the particular node implementation mechanisms which realize a 
per-nop behavior. 

Service provisioning and traffic conditioning policies are 
sufficiently decoupled from the forwarding behaviors within the 
network interior to permit implementation of a. wide variety of 
service behaviors, with room for future expansion. 

Th-i* architecture only provides service differentiation in one 
direction of traffic >low and is therefore. asymmetric development 
of a complementary symmetric architecture is a, topic of current 
research but is outside the scope of this document; see for example 

[EXPLICIT] . 

Sect. 1.2 is a glossary of terms used within this document. Sec. 1.3 
lists requirements addressed by this architecture, and Sec. 1.4 
provides a brief comparison to other approaches for service 
differentiation. Sec. 2 discusses the components of the architecture 

Blake, et. al. informational E. Pa 9 e 3] 

RFC 2475 Architecture .for Differentiated Services December 1998 

in detail Sec. 3 proposes guidelines for per-hop behavior 
specifications Sec. 4 discusses interoperability issues with nodes 
ISd C nelwfrkrwnich e do not Implemeni | differentiated services as 
defined in this document and in [DSFIELD] . Sec . 5 discus ses issues 
with multicast service delivery. Sec. 6 addresses security and 
tunnel considerations. 

1.2 Terminology 

This section gives a general conceptual overview of the terms used in 
' this document Some of these terms are more precisely defined in 
later sections of this document. 

Behavior Aggregate (ba) a DS behavior aggregate. 

ba classifier a classifier that selects packets based 
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only on the contents of the DS field. 

a link connecting the edge nodes of two 
domains. 

an entity which selects packets based on 
the content of packet headers according to. 
defined rules. 

a collection of packets with the same DS 
codepoint crossing a link in a particular 
direction. 

a DS node that connects one DS domain to a 
node either in another DS domain or in a 
domain that is not DS-capable. 

capable of implementing differentiated 
services as described in this architecture; 
usually used in reference to. a domain * 
consisting of DS-compliant nodes." 

a specific value of the DSCP portion of the 
DS field, used to select a PHB. 

enabled to support differentiated, services 
functions and behaviors as defined in 
[DSFIELD], this document, and other 
di f f erenti ated servi ces documents ; usual Ty 
used in reference to a node or device. 
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DS domain 



DS egress node 

DS ingress node 

DS i nterior node 
DS field 



DS node 
DS region 



a DS-capable domain; a contiguous set of 

nodes which operate with a common set of 

service provisioning policies and PHB 
definitions. 

a DS boundary node in its role in handling 
traffic as it leaves a DS domain. 

a DS boundary node in its role in handling 
traffic as it enters a DS domain. 

a DS node that is not a DS boundary node. 

the IPv4 header TOS octet or the IPv6 
Traffic Class octet when interpreted in 
conformance with the definition given in 
[DSFIELD]. The bits of the DSCP field 
encode the DS codepoint, while the 
remaining bits are currently unused. 

a DS-compliant node. 

a set of contiguous DS domains which can 
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offer differentiated services over paths 
across those DS domains. 

the DS domain downstream of traffic flow on 
a boundary link. 

a device that performs dropping. 

the process of discarding packets based on 
specified rules; policing. 

a node which implements IPv4 Precedence as 
defined in [RFC791, RFC1812] but which is 
otherwise not DS-compliant. 

a device that performs marking. 

the process of setting the DS codepoint in 
a packet based on defined rules; pre- 
marking, re-marking. 

a specific algorithm or operation (e.g., > 
queueing discipline) that is implemented in 
a node to realize a set of one or more per- 
hop behaviors. 
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Meter 
Metering 



Mi crofl ow 



MF classifier 



Per-Hop-Behavior (phb) 



PHB group 



a device that performs metering. 

the process of measuring the temporal 
properties (e.g., rate) of a traffic stream 
selected by a classifier. The 
instantaneous state of this process may be 
used to affect the operation of a marker, 
shaper, or dropper, and/or may be used for 
accounting and measurement purposes. 

a single instance of an application-to- 
application flow of packets which is 
identified by source address, source port, 
destination address, destination port and 
protocol id. 

a multi -field (MF) classifier which selects 
packets based on the content of some 
arbitrary number of header fields; 
typically some combination of source 
address, destination address, DS field, 
protocol ID, source port and destination 
port. 

the externally observable forwarding 
behavior applied at a DS-compliant node to 
a DS behavior aggregate. 

a set of one or more PHBs that can only be 
meaningfully specified and implemented 
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simultaneously, due to a common constraint 
applying to all phbs in the set such as a 
queue servicing or queue management policy. 
A phb group provides a service building 
block that allows a set of related 
forwarding behaviors to be specified 
together (e.g., four dropping priorities). 
A single phb is a special case of a phb 
group. 

the process of discarding packets (by a 
dropper) within a traffic stream in 
accordance with the state of a 
corresponding meter enforcing a traffic 
profile. 

to set the DS codepoint of a packet prior 
to entry into a downstream DS domain. 
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Provider DS domain 



Re-mark 



Service 



Service Level Agreement 
(SLA) 



Service Provisioning 
Policy 



Shaper 
Shapi ng 

Source domain 

Traffic conditioner 



the DS-capable provider of services to a 
source domain. 

to change the DS codepoint of a packet, 
usually performed by a marker in accordance 
with a TCA. * 

the overall treatment of a defined subset 
of a customer's traffic within a DS domain 
or end-to-end. 

a service contract between a customer and a 
service provider that specifies the 
forwarding service a customer should 
receive, a customer may be a user 
organization (source domain) or another DS 
domain (upstream domain), a SLA may 
include traffic conditioning rules which 
constitute a TCA in whole or in part/ 

a policy which defines how traffic 
conditioners are configured on DS boundary 
nodes and how trafftc streams are mapped to 
DS behavior aggregates to achieve a ranqe 
of services. 

a device that performs shaping. - 

the process of delaying packets within a 
traffic stream to cause it to conform to 
some defined traffic profile. 

a domain which contains the node(s) 
originating the traffic receiving a 
particular service. 

an entity which performs traffic 
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conditioning functions and which may 
contain meters, markers, droppers, and 
shapers. Traffic conditioners are typically 
deployed in DS boundary nodes only. A 
traffic conditioner may re-mark a traffic 
stream or may discard or shape packets to 
alter the temporal characteristics of the 
stream and bring it into compliance with a 
traffic profile. 
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Traffic conditioning 



Traffic Conditioning 
Agreement (TCA) 



Traffic profile 



Traffic stream 



upstream DS domain 



control functions performed to enforce 
rules specified in a TCA, including f 
metering, marking, shaping, and policing. 

an agreement specifying classifier rules 
and any corresponding traffic profiles and 
metering, marking, discarding and/or 
shaping rules which- are to apply to the 
traffic streams selected by the classifier. 
A TCA encompasses all of the traffic 
conditioning rules explicitly specified 
within a SLA along with all of the rules 
implicit from the relevant service t j 
requirements and/or from a DS domain s 
service provisioning policy. 

a description of the temporal properties 
of a traffic stream such as rate and burst 
size. 

an administratively significant set of one 
or more microflows which traverse a path 
segment. A traffic stream may consist of 
the set of active microflows which are 
selected by a particular classifier. 



the DS domain upstream 
boundary link. 



of traffic flow on a 



1.3 Requirements 

The history of the Internet has. been one of continuous growth in the 
number of hosts, the number and variety of applications, and the 
capacity of the network infrastructure, and this growth is expected 
to continue for the foreseeable future. A scalable architecture for 
service differentiation must be able to accommodate this contrnuea 
growth. 



The following requirements were identified and are addressed in 
architecture: 

o should accommodate a wide variety of services and provisioning 
policies, extending end-to-end or within a particular tset ot; 
network(s) , 
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should allow decoupling of the service from the particular 
application in use, 
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o should wcjrk.wfth existing applications without the need for 
application programming interface changes or host software 
modifications (assuming suitable deployment of classifiers, 
markers, and other traffic conditioning functions), 

o should decouple traffic conditioning and service provisioning 
functions from forwarding behaviors implemented within the core 
network nodes, . 

o should not depend on hop-by-hop application signaling, 

o should require only a small set of forwarding behaviors whose 
implementation complexity does not dominate the cost of a network 
device, and which will not introduce bottlenecks for future high- 
speed system implementations, 

o should avoid per-microflow or per-customer state within core 
network nodes, 

o should utilize only aggregated classification state within the 
network core, 

o should permit simple packet classification implementations in core 
network nodes (BA classifier), 

o should permit reasonable interoperability with non-DS-compliant 
network nodes, 

o should accommodate incremental deployment. 
1.4 Comparisons with Other Approaches 

The differentiated services architecture specified in this document 
can be contrasted with other existing models of service 
differentiation, we classify these alternative models into the 
tol lowing categories: relative priority marking, service marking, 
label switching, Integrated Services/RSVP, and static per-hop 
classification. 

Examples of the relative priority marking model include IPv4 
Precedence marking as defined in [RFC791], 802.5 Token Ri rig. priority 
r!n=K a ? d the d *f ault interpretation of 802. lp traffic classes 
LoU^.lpJ. in this model the application, host, or proxy node selects 
a relative priority or "precedence' 1 for a packet (e.g., delay or 
discard priority), and the network nodes along the transit path apply 
the appropriate priority forwarding behavior corresponding to the 
priority value within the packet 1 s header. Our architecture can be 
considered as a refinement to this model, since we more clearly 
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specify the role and importance of boundary nodes and traffic 
conditioners, and since our per-hop behavior model permits more - 
general forwarding behaviors than relative delay or discard priority. 

An example of a service marking model is IPv4 TOS as defined in 
[RFC13491. in this example each packet is marked with -a request for 
a "tvoe of service", which may include "minimize delay , maximize 
throughput", "maximize reliability", or "minimize cost Network 
nodes may select routing paths or forwarding behaviors which are 
suitably engineered to satisfy the service request. This model is 
subtly different from our architecture. Note that we do not describe 
the use of the DS field as an input to route selection. The TOS 
markings defined in' [RFC1349] .are very generic and dp not span the 
ranqe of possible service semantics. Furthermore, the service 
request is :'associated with each individual packet, whereas some 
service semantics may depend on the aggregate forwarding behavior of 
a sequence of packets. The service marking model does not easi ly 
accommodate growth in the number and range of future services (.since 
the codepoint space is small) and involves configuration of the 
"TOS->forwarding behavior" association in each core network node. 
Standardizing service markings implies standardizing service 
offerings, which is outside the scope of the IETF. Note that 
provisions are made in the allocation of the DS codepoint space to 
allow for locally significant codepoints which may be used by a 
provider to support service marking semantics [DSFIELDJ . 

Examples of the label switching (or virtual circuit)' model include 
Frame Relay, ATM, and MPLS [FRELAY, ATM] . In this model path 
forwarding state and traffic management or QoS state is estaonsneo 



for traffic streams on each hop along a network path. Trarric 
aqqregates of varying granularity are associated with a label 
switched path at an ingress node, and packets/cells within ead 
switched path are marked with a forwarding label that is used to 
lookup the next-hop node, the per-hop forwarding behavior, and the 
replacement label at each hop. This model permits finer granularity 
resource allocation to traffic streams, since label values are not 
globally significant but are only significant on a single link; 
therefore resources can be reserved for the aggregate of packets/ 
cells received on a link with a particular label , and the label 
switching semantics govern the next-hop selection, allowing a trarric 
stream to follow a specially engineered path through the network. 
'This improved granularity comes at the cost of additional management 
and configuration requirements to establish and maintain the laoei 
switched paths. In addition, the amount of forwarding state _ 
maintained at each node scales in proportion to the number ot edge 
nodes of the network in the best case (assuming multi point-to-point 
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label switched paths), and it scales in proportion with the square of 
the number of edge nodes in the worst case, when edge-edge label 
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switched, paths with provisioned resources are employed. 

The Integrated Services/RSVP model relies upon traditional datagram 
forwarding in the default case, but allows sources and receivers to 
exchange signaling messages. whi ch establish additional packet 
classification and forwarding state on each node along the path 
between them [RFC1633., rsvp] . in the absence of state aggregation, 
the amount of state on each node scales in proportion to the number 
of concurrent reservations, which can be potentially large on high- 
speed links. This model also requires application support for the 
RSVP signaling protocol. Differentiated services mechanisms can be 
utilized to aggregate Integrated Services/RSVP state in the core of 
the network [Bernet] . . 

A variant of the Integrated Services/RSVP model eliminates the 
requirement for hop-by-hop signaling by utilizing only "static" 
classification and forwarding policies which are implemented in each 
node along a network path. These policies are updated on 
administrative ti mescal es and not in response to the instantaneous 
mix of microflows active in the network. The state requi regents .for 
this variant are potentially worse than those encountered when RSVP . 
is used, especially in backbone nodes, since the number of static 
policies that might be applicable at a node over time may be larger 
than the number of active sender-receiver sessions that might have 
installed reservation state on a node. Although the support of Targe 
numbers of classifier rules and forwarding policies may be 
computationally feasible, the management burden associated with 
installing and maintaining these rules on each node within a backbone 
network which might be traversed by a traffic stream is substantial: 

Although we contrast our architecture with these alternative models 
of service differentiation, it should be noted that links and nodes 
employing these techniques may be utilized to extend differentiated 
services behaviors and semantics across a layer-2 switched 
infrastructure (e.g., 802. Ip LANs, Frame Relay/ATM backbones) 
interconnecting ds nodes, and in the case of MPLS may be used as an 
alternative intra-domain implementation technology. The constraints 
imposed by the use of a specific link-layer technology in particular 
regions of a DS domain (or in a network providing access to DS 
domains) may imply the differentiation of traffic on a coarser grain 
basis. Depending on the mapping of PHBs to different link-layer 
services and the way in which packets are scheduled over a restricted 
set of priority classes Cor virtual circuits of different category 
and capacity), all or a subset of the PHBs in use may be supportable 
(or may be indistinguishable). 
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2. Differentiated Services Architectural Model 

The differentiated services architecture is based on a simple model 
where traffic entering a network is classified and possibly 
conditioned at the boundaries of the network, and assigned to 
different behavior aggregates. Each behavior aggregate is identified 
by a single DS codepoint. within the core of the network, packets 
are forwarded according to the per-hop behavior associated with the 
DS codepoint. in this section, we discuss the key components within 
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a differentiated services region, traffic classification and 
conditioning functions, and how differentiated services are achieved 
through the combination of traffic conditioning and PHB-based 
forwarding. 

2.1 Differentiated Services Domain 

A DS domain is a contiguous set of DS nodes which operate with a 
common service provisioning policy and set of PHB groups implemented 
on each node. A DS domain has a well -defined boundary consisting of 
DS boundary nodes which classify and possibly conditicm ingress 
traffic to ensure that packets which transit the domain are 
appropriately marked to select a PHB from one of the PHB groups 
supported within the domain. Nodes within the DS domain select the 
forwarding behavior for packets based on their DS codepoint, mapping 
that value to one of the supported PHBs using either the recommended 
codepoint->PHB mapping or a locally customized mapping [DSFIELD] . 
Inclusion. of non-DS-compliant nodes within a DS domain. may result in 
unpredictable performance and may impede the ability to satisfy 
service leVel agreements (sLas) . 

A DS domain normally consists of one or more networks under the same 
administration; for example, an organization's intranet or an ISP. 
The administration of the domain is responsible for ensuring that 
adequate resources are provisioned and/or reserved to support the 
SLAs offered by the domain. 

2.1.1 DS Boundary Nodes and Interior Nodes 

A DS domain consists of DS boundary nodes and DS interior nodes. DS 
boundary nodes interconnect the DS domain to other DS or non-DS- 
capable domains, whilst DS interior nodes only connect to other DS 
interior or boundary nodes within the same DS domain. 

Both DS boundary nodes and interior nodes must be able to apply the 
appropriate PHB to packets based on the DS codepoint; otherwise 
unpredictable behavior may result. In addition, DS boundary nodes 
may be required to perform traffic conditioning functions as defined 
by a traffic conditioning agreement (TCA) between thei r DS domain and 
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the peering domain which they connect to (see Sec. 2.3.3). 

Interior nodes may be able to perform limited traffic condi tioning. 
functions such as DS codepoint re-marking. Interior nodes which 
implement more complex classification and traffic condl ^5 n ] n 9. 
functions are analogous to DS boundary nodes (see Sec 2.3.4.4;. 

A host in a network containing a DS domain may act as a DS boundary 
node for traffic from applications running on that host; we therefore 
say that the host is within the DS domain. If a host does not act as 
a boundary node, then the DS node topologically closest to that host 
acts as tne DS boundary node for that host's traffic. 

2.1.2 DS ingress Node and Egress Node. 

DS boundary nodes act both as a DS ingress node and as a DS egress 
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node for different directions of traffic. Traffic enters a DS domain 
at a DS ingress node and leaves a DS domain at a DS egress node. A 
DS ingress node is responsible for ensuring that the traffic entering 
the DS domain conforms to any TCA between it and the other domain to 
which the ingress node is connected. A DS egress node may perform, 
traffic conditioning functions' on traffic forwarded to a directly 
connected peering domain, depending on the details of the TCA between 
the two domains. Note that a DS boundary node may act as a DS 
interior node for some set of interfaces. 

2.2_ Differentiated Services Region 

A differentiated services region (DS Region) is a set of one or more 
contiguous DS domains. DS regions are capable of supporting 
differentiated services along paths which span the domains within the 
region. 

The DS domains in a DS region may support different phb groups 
internally and different codepoint->PHB mappings. However, to permit 
services which span across the domains, the peering DS domains must 
each establish a peering SLA which defines (either explicitly or 
implicitly) a TCA which specifies how transit traffic from one DS 
domain to another is conditioned at the boundary between the two DS 
domains. '< . - 

It is possible that several DS domains within a DS region may adopt a 
common service provisioning policy and may support a common set of 
phb groups and codepoint mappings, thus eliminating the need for 
traffic conditioning between those DS domains. 
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2.3 Traffic Classification and Conditioning 

Differentiated services are extended across a DS domain boundary by 
establishing a SLA between an upstream network and a downstream DS 
domain. The SLA may specify packet classification and re-marking 
rules and may also specify traffic profiles and actions to traffic 
streams which are in- or out-of-prof i le (see Sec. 2.3.2). The. TCA 
between the domains is derived (explicitly or implicitly) from this 
• SLA. 

The packet classification policy identifies the subset of traffic 
which may receive a differentiated service by beiing conditioned and/ 
or mapped to one or more behavior aggregates (by DS cadepoint re- 
marking) within the DS domain. 

Traffic conditioning performs metering, shaping, policing and/or re- 
- marking to ensure that the traffic entering the DS domain conforms to 
the rules -specified in the tca, in accordance with the domain's, 
service provisioning policy. The extent of traffic conditioning 
required is dependent on the specifics of the service offering, and 
may range from simple codepoint re-marking to complex policing and 
shaping operations. The details of traffic conditioning policies 
which are negotiated between networks is outside the scope of this 
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2.3.1 Classifiers 

Packet classifiers select packets in a traffic stream based on the 
content of some portion of the packet header, we define two types of 
classifiers. The ba (Behavior Aggregate) Classifier classifies 
packets based on the DS codepoint only. The mf (Multi -Fie Id} 
classifier selects packets based on the value of a combination of one 
or more header fields, such as source address, destination address, 
DS field, protocol ID, source port and destination port numbers, and 
other information such as incoming interface. 

Classifiers are used to "steer" packets matching some specified rule 
to an element of a traffic conditioner for further processing. 
Classifiers must be configured by some management procedure in 
accordance with the appropriate TCA. 

The classifier should authenticate the information which it uses to 
classify the packet (see Sec. 6). 

Note that in the event of upstream packet fragmentation, MF 
classifiers which examine the contents of transport-layer header 
fields may incorrectly classify packet fragments subsequent to the 
first. A possible solution to this problem is to maintain 
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fragmentation state; however, this is not a general solution due to 
the possibility of upstream fragment re-ordering or divergent routing 
paths. The policy to apply to packet fragments is c 
of this document. 



outside the scope" 



2.3.2 Traffic Profiles 



A traffic profile specifies the temporal properties of a traffic 
stream selected by a classifier. It provides rules for determining 
whether a particular packet is in-profile or out-of-proti I e. For 
example, a profile based on a token bucket may look like: 

codepoint=x, use token-bucket r, b 

The above profile indicates that all packets marked with DS codepoint 
x should be measured against a token bucket meter with rate r and 
burst size b. In this example out -of -profile packets are those 
packets in the traffic stream which arrive when insufficient tokens 
are available in the; bucket. The concept of in- and out-of-proti l e 
can be" extended to more than two levels, e.g., multiple levels ot 
conformance with a profile may be defined and enforced.. 

Different conditioning actions may be applied to the in-profile 
packets and out-of -profile packets, or different accounting actions 
may be triggered. In-profile packets may be allowed to enter the DS 
domain without further conditioning; or, alternatively, their DS 
codepoint may be changed. The latter happens when the DS codepoint 
is set to a non-Default value for the first time [DSFIELD] , or when 
the packets enter a DS domain that uses a different PHB group or 
codepoint->PHB mapping policy for this traffic stream. Out-of- 
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profile packets may be queued until they are m-profile (shaped;, 
discarded (policed), marked with a new codepoint (re-marked), or 
forwarded* unchanged while triggering some accounting procedure, 
out-of-profile packets may be mapped to one or more behavior 
aggregates that are "inferior" in some dimension of forwarding 
performance to the BA into which in-profile packets are mapped. 

Note that a traffic profile is an optional component of a TCA and its 
use is dependent on the specifics of the service offering and the 
domain's service provisioning policy. 

2.3.3 Traffic Conditioners 

A traffic conditioner may contain the following elements: meter, 
marker, shaper, and dropper. A traffic stream is selected by a 
classifier, which steers the .packets to a logical instance^of a 
traffic conditioner. A meter is used (where appropriate) to measure 
the traffic stream against a traffic profile. The state of the meter 
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with respect to a particular packet (e.g., whether it is in- or out- 
of-profile) may be used to affect a marking, dropping, or shaping 
action. 

when packets exit the traffic conditioner of a DS boundary node the 
DS codepoint of each packet must be set to an appropriate value. 

Fig. 1 shows the block diagram of a classifier and traffic 
conditioner. Note that a traffic conditioner may not necessarily 
contain all four elements. For example, in the case where no traffic 
profile is in effect, packets may only pass through a classifier and 
a marker. 



+- 
-+ 



Meter | 



--+ 



packets =====: 



+ .+ + -. 

I I I • 

>| Classifier | =====>! Marker 



V 

+■■ — ■ + 

| Shaper/ I 
:>| Dropper | 

+ — + 



Fig. 1: Logical view of a Packet Classifier and Traff4c, Conditioner 



2.3.3.1 Meters 



meters measure the temporal properties of the stream of 
selected by a classifier against a traffic profile specified 



Traf f i c 

in a TCaT "A^mete^passes^state information to other conditioning 
functions to trigger a particular action for each packet which is 
either in- or out-of-profile (to some extent). 



2.3.3.2 Markers 
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Packet markers set the DS field of a Packet rt ^Ihavior 

codepoint, adding the marked packet to a particular ds behavior 
aggregate The marker may be configured to mark all P^f" which 
tre steered to it to a single codepoint, or may be configured to mark 
a packet to one of a set of codepoints "*e d ^° s fjf * L™ B C JJ * e s 
group, according to the state of a. meter. When the marker changes 
the codepoint in a packet it is said to have "re-marked the packet. 
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2.3.3.3 Shapers 



Shapers delay some or all of the packets in a traffic stream in order 
to bring the stream into compliance with a traffic .Profile, A shaper 
S?ual yhas a finite-size buffer, and P^kets may be discarded if 
there is not sufficient buffer space to hold the delayed packets. 

2.3.3.4 Droppers 

Droppers discard some or all of the packets in a traffic stream in 
order to bring the stream into compliance with a traffic prof He. 
?h?f process ?s know as "policing" the stream Note that a dropper 
can be implemented as a special case of a shaper by setting the 
shaper buffer size to zero (or a few) packets., 

2.3.4 Location of Traffic Conditioners and MF Classifiers . 

Traffic conditioners are usually located within DS 4"?>; e "/ n J t !^ss 
boundary nodes, but may also be located in nodes within the interior 
of a DS domain, or within a non-DS-capable domain. 

2.3.4.1 within the Source Domain 

we define the source domain as the. domain containing the node CO 
which originate the traffic receiving a particular servi ce . Trarti c 
sources and intermediate nodes within a source domain may perform 
traffic classification and conditioning functions. The trarric 
o r riginating S from"he source domain across ^boundary may be marked by 
the traffic sources directly or by intermediate nodes before leaving 
the source domain. This is referred to as initial marking or pre 
marking". 

Consider the example. of a company that has the policy that jts CEO^s 
packets should have higher priority. The CEO s host may mark the DS 
field of all outgoing packets with a DS codepoint that indicates 
"higher priority*. Alternatively, the fi rst-hop router directly 
connected to the CEO's host may classify. the traffic and mark th 
CEO's packets with the correct DS codepoint. Such high Priority 
traffic may also be conditioned near the source so that there 
limit on the amount of high priority traffic forwarded from, a 
particular source. 

There are some advantages to marking packets close to the traffic 
source. First, a traffic source can more easily take an 
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application's preferences into account when deciding which packets 
should receive better forwarding treatment. Also, classification of 



Blake, et. al . Informational [Page 17] 

D - 

RFC 2475 Architecture for Differentiated Services December 1998 

packets is much simpler before the traffic has been aggregated with 
packets from other sources, since the number of classification rules 
which need to be applied within a single node i^ reduced.. 

Since packet marking may be distributed across multiple nodes, the 
source DS domain is responsible for ensuring that the aggregated 
traffic towards, its provider DS domain conforms to the appropriate 
TCA. Additional allocation mechanisms such as bandwi dth: brokers or 
RSVP may be used to dynamically allocate resources for a particular 
DS behavior aggregate within the provider's network [2BIT, Bernet] . 
The boundary node of the source domain should also monitor 
conformance to the TCA, and may police, shape, or re-mark packets as 
necessary. 

2.3.4.2 At the Boundary of a DS Domain 

Traffic streams may be classified, marked, and otherwise conditioned 
on either end of a boundary link (the DS egress node of the upstream 
domain or the DS ingress node of the downstream domain). The SLA 
between the domains should specify which domain has responsibility 
for mapping traffic streams to DS behavior aggregates and 
conditioning those aggregates in conformance with the appropriate 
TCA. However, a DS ingress node must assume that the incoming 
traffic may not conform to the TCA and must be prepared to enforce 
the TCA in accordance with local policy. 

when packets are pre-marked and conditioned in the upstream domain, 
potentially fewer classification and traffic conditioning rules need 
to be supported in the downstream DS domain. In this circumstance 
the downstream DS. domain may only need to re-mark or police the 
incoming behavior aggregates to enforce the TCA. However, more 
sophisticated services, which are path- or source-dependent may 
require MF classification in the downstream DS domain's ingress 
nodes. 

If a DS ingress node is connected to an upstream non-DS-capable 
domain, the DS ingress node must be able to perform all necessary 
traffic conditioning functions on the incoming traffic. 

2.3.4.3 in non-DS-capable Domains 

Traffic sources or intermediate nodes in a non-DS-capable domain may 
employ traffic conditioners to pre-mark traffic before it reaches the 
ingress of a downstream DS domain, in this way the local policies 
for classification and marking may be concealed. 
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2.3.4.4 In interior DS Nodes 

Although the basic architecture assumes that complex classification 
and traffic conditioning functions are located only in a network s 
tigress" and egress boundary nodes, deployment of these functions in 
the interior of the network is not precluded. For example, more 
restrictive access policies may be enforced on. a transoceanic link, 
requiring MF classification and traffic conditioning funct onality in 
the upstream node on the link. This approach may ha Y$, paling 
limits, due to the potentially large number. of classification and 
conditioning rules that might need to be maintained. 

2.4 Per-Hop Behaviors 

A per-ii«>p behavior (phb) is a description of the externally 
observable forwarding behavior of a DS node applied to a particular 
DS behavior aggregate.* "Forwarding behavior" is a general concept in 
this context For example, in the event that only one behavior 
aaareoate occupies a link, the observable forwarding behavior (i.e., 
loJs delay jitter) will often depend only on the relative loading 
' of the 1 nk\i I in the event that the behavior assumes a.work- 
conserv ing schedu ing discipline), useful behavioral dictions 
Ire mainl? observed when multiple behavior aggregates compete for 
buffer and bandwidth resources on a node.. The PHB is the means py 
which a node allocates resources to behavior aggregates and it is on 
top of this basic hop-by-hop resource allocation mechanism that 
useful differentiated services may be constructed. 

The most simple example of a PHB is one which guarantees a min^al 
. bandwidth allocation of x% of a link (over some reasonable time 
interval) to a behavior aggregate.. This PHB can be fairly easily, 
measured under a variety of competing traffic conditions A .slightly 
more complex PHB would guarantee a minimal bandwidth allocation or x*> 
of a link, with proportional fair sharing of any excess nnK . ^ , 
dole ty In general, the observable behavior of a PHB may depend on 
cer?ain y cons!rIints on the traffic characteristics of the associated 
behavior aggregate, or the characteristics of other behavior 
aggregates. 

PHBs may be specified in terms of their resource (e.g., buffer , 
bandwidth) priority relative to other. PHBs, or in terms of their 
relative observable traffic characteristics (e.g., delay, los .s). 
These PHBs may be used as building blocks to alTocate resources and 
should be specified as a group (PHB group). for consi stency . PHB 
groups will usually share a common constraint applying^to each PHB 
within the group, such as a packet scheduling or buffer management 
policy. The relationship between PHBs in a group may be in terms of 
absolute or relative priority (e.g., discard priority by means of 
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deterministic or stochastic thresholds), but this is not required 
(e q., n equal link shares). A single PHB denned in isolation is a 
3 • Page 17 
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special case of a'PHB group. 

PHBs are implemented in nodes by means of some buffer management and 
packet scheduling mechanisms, phbs are defined in terms of behavior 
characteristics relevant to service provisioning policies, and not in 
terms of particular implementation mechanisms, in general, a variety 
of implementation mechanisms may be suitable. for implementing a 
particular PHB group. Furthermore, it is likely that more than one 
PHB group may be implemented on a node and utilized within a domain. 
PHB groups should be defined such that the proper resource allocation 
between groups can be inferred, and integrated mechanisms can be 
implemented which can simultaneously support two or more groups. A 
PHB group definition should indicate possible conflicts with 
previously documented PHB groups which might prevent simultaneous 
operation. 

As described in [DSFIELD] , a PHB is selected at a node by a mapping 
of the DS codepoint in a received packet, standardized PHBs have a 
recommended codepoint. However, the total space of codepoints is 
larger than the space available for recommended codepoin'trs for 
standardized PHBs, and [DSFIELD] leaves provisions for locally 
configurable mappings. A codepoint->PHB mapping table may contain 
both 1->1 and N->1 mappings. All codepoints must be mapped to some - 
PHB; in the absence of some local policy, codepoints which are not 
mapped to a standardized PHB in accordance with that PHB 1 s 
specification should be mapped to the Default PHB. 

2.5 Network Resource Allocation 

The implementation, configuration, operation and administration of 
the supported PHB groups in the nodes of a DS Domain should 
effectively partition the resources of those nodes and the inter-node 
links between behavior aggregates, in accordance with the domain's 
service provisioning policy. Traffic conditioners can further 
control the usage of these resources through enforcement of TCAs and 
possibly through operational feedback from the nodes and traffic 
conditioners in the domain. Although a range of services can be 
deployed in. the absence of complex traffic conditioning functions 
(e.g., using only static marking policies), functions such as 
policing, shaping, and dynamic re-marking enable the deployment of 
services providing quantitative performance metrics.. 

The configuration of and interaction between traffic conditioners and 
interior nodes should be managed by the administrative control of the 
domain and may require operational control through protocols and a 
control entity. There is a wide range of possible control models. 
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The precise nature and implementation of the interaction between 
these components is outside the scope of this architecture. However, 
scalability requires that the control of the domain does not require 
micro-management of the network resources. The most scalable control 
model would operate nodes in open-loop in the operational timeframe, 
and would only require admini strati ve-timescale management as SLAs 
are varied. This simple model may be unsuitable in some 
circumstances, and some automated but slowly varying operational 
control (minutes rather than seconds) may be desirable to balance the 
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utilization of the network against the recent load pron le. 

3. per-Hop Behavior Specification Guidelines 

Basic reoui rements for per-hop behavior standardization are given in 
[dsfield? This sectioK elaborates on that text. by describing 
addition! guidelines for phb (group) specifications This is 
intended to help foster implementation. consistency. Before a phb 
aroup is proposed for standardization it should satisfy these 
guidelines as appropriate, to preserve the integrity of this 
architecture. 

G.l: A PHB standard must specify a recommended ^scodepoint selected 
from the codepoint space .reserved for standard mappings [DSFIELDJ. 
Recommended codepoints will be assigned by the^IANA A PHB proposal 
mav recommend a temporary codepoint from the EXP/LU spacero narker's 
facilitate inter-domain experimentation ^^KrSJadJr f?Sdf 
PHB must not require inspection of additional packet header neias 
beyond the DS field. 

G 2- The specification of each newly proposed PHB 9roup should _ 
include an overview of the behavior and the purpose of the behavior 
being proposed The overview should include a problem or P^blem 
statement for which the PHB group is targeted. The overview snou .u 

or problems specified in the problem statement. 

G 3- A PHB group specification should indicate the number of 
individual phbs specified, in the event that multiple phbs are 
specified the interactions between these PHBS and constraints that 
mult be respected globally by all the PHBs within. the group should be 
clearlj spSified. As anexample, the specification must indicate 
whether the probability, of packet reordering within a ™croflow is 
increased if different packets in that microflow are marked for 
different PHBs within the group. 
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G.4: when proper functioning of a PHB group is dependent on 
rnnstraints such as a provisioning restriction, then the phb 
define on" should delcfibe the befiavior when these constraints are 
violated Further, if actions such as Packet discard or re-mark ng 
are required when these constraints are violated, then these actions 
sHhbuTd be specifically stipulated. 

G 5- A PHB group may be specified for local use within a domain in 
order to provided domain-specific functionality or domain- 
specific services. In this event, the PHB specification is useful 
for providing vendors with a consistent definition of the PHB group. 
Howeve? any PHB group which is- defined for local use should not be 
considered for standardization, but may be published as an 
informational RFC . In contrast, a PHB group which ^intended tor 
npneral use will follow a stricter standardization process. 
Therefore 111 PHB proposals should specifically state whether they 
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are to be considered for general or local use. 

It is recognized that PHB groups can be designed with the intent of 
providing host-to-host, wan edge-to-WAN edge, and/or domain edge-to- 
domain edge services, use of the term "end-to-end" in a PHB 
definition should be interpreted to mean "host-to-host" for 
consistency. 

Other PHB groups may be defined and deployed locally within domains, 
tor experimental or operational purposes. There is no requirement 
that these PHB groups must be publicly documented, but they should 
[dsfield] S epolnts from one of the Exp Au pools as defined in 

G.6: it may be possible or appropriate for a packet marked for a PHB 
within a PHB group to be re-marked to select another PHB within the 
group; either within a. domain or across a domain boundary. Typically 
there are three reasons for such PHB modification: 

a. The codepoints associated with the PHB group are collectively 
intended to carry state about the network, 

b. Conditions exist which require PHB promotion or demotion of a 
packet (this assumes that PHBs within the group can be ranked in 
some order) , 

c. The boundary between two domains is not covered by a SLA. in this 
c *f? J he codepoint/PHB to select when crossing the boundary link • 
will be determined by the local policy of the upstream domain. 

A PHB specification should clearly state the circumstances under 
which packets marked for a PHB within a PHB group may, or should be 
modified (e.g., promoted or demoted) to another PHB within the group. 
If it is undesirable for a packet's PHB to be modified, the 
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specification should clearly state the consequent risks when the PHB 
is modified. a possible risk to changing a packet's PHB, either 
within or outside a PHB group, is a higher probability of packet re- 
ordering within a microflow. PHBs within a group may carry some 
host-to-host, wan edge-to-WAN edge, and/or domain edge-to-domain edge 
semantics which may be difficult to duplicate if packets are re- 
marked to select another phb from the group (or otherwise). 

For certain phb groups, it may be appropriate to reflect a state 
change in the node by re-marking packets to specify another PHB from 
within the group, if a PHB group is designed to reflect the state of 
a network, the PHB definition must adequately describe the 
relationship between the PHBs and the states they reflect. Further, 
it these PHBs limit the forwarding actions a node can perform in some 
way, these constraints may be specified as actions the node should, 
or must perform. 

G.7: A PHB group specification should include a section defining the 
implications of tunneling on the utility of the PHB group. This 
section should specify the implications for the utility of the PHB 
group of a newly created outer header when the original DS field of 
the inner header is encapsulated in a tunnel. This section should 
■ also discuss what possible changes should be applied to the inner 
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header at the egress of the tunnel, when both the codepoints from the 
inner header and the outer header are accessible (see sec. b.i). 

G.8: The process of specifying phb groups is likely to be 
incremental in nature. When new PHB groups are proposed their known 
interactions with previously specified PHB groups should J>e 
documented. When a new PHB group is created it can be entirely new 
in scope or it can be an extension to an existing PHB group. If the 
PHB qroup is entirely independent of some or all pf the existing phb 
spec?fi cations, a section should be included in the PHB specification 
which details how the new PHB group can co-exist with those PHB 
groups already standardized. For example, this section might 
indicate the possibility of packet re-ordering within a microflow-for 
packers marked by codepoints associated with two separate PHB groups. 
Sf concurrent operation of two (or more) different PHB groups in the 
same node is impossible or detrimental this should be stated, "the 
concurrent operation of two (or more) different PHB ?/oups requ res 
some specific behaviors by the node when packets marked for phbs from 
these, different PHB groups are being processed by the node at tne 
same ; :t.ime, these behaviors should be stated. 

care should be taken to avoid circularity in the definitions of PHB 
groups. 
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If the proposed PHB group is an extension to an existing PHB group, a 
section should be included in the PHB group specification which 
details how this extension i nteroperates with the behavior_ being 
extended. Further, if the extension alters or more nar row! y defines 
the existing behavior in some way, this should also be clearly 
indicated. 

G.9: Each PHB specification should include a section specifying 
minimal conformance requirements for implementations , ot the phb 
group. This conformance section is intended to provide a means tor 
specifying the details of a behavior while allowing for 
implementation variation to the extent permitted by the PHB 
specification. This conformance section can take the form of rules, 
tables, pseudo-code, or tests. 

G.10: a PHB specification should include a section detailing the 
security implications of the behavior. This section shoud include a 
discussion of the re-marking of the inner header s codepqint at the 
egress of a tunnel and its effect on the desired forwarding behavior. 

Further, this section should also discuss how the Proposed, phb group 
could be used in denial-of-service attacks, reduction pf service 
contract attacks, and service contract violation attacks.. Lastly, 
this section should discuss possible means for detecting such attacks 
as they are relevant to the proposed behavior. 

G.ll: A PHB specification should include a section ^tailing 
configuration and management issues which may affect the operation ot 
the PHB and which may impact candidate services that might utilize 
the phb. 

Page 21 



346849_1 

M^pu^ci! ?K° n ^ y ^commended that an appendix be provided with 

„ ^ C1 f lcatl0n that considers the implications of the 
c2?d SnSdS^E 2" CUr T ent and P^ential services. These services 

f n c1 ^L but are not restricted to be user-specific, device- 
specific, domain-specific or end-to-end services It is also 

hSw°;gl y s . r rv? m r a ded th3 V he appendix include I section describing 
how the services are verified by users, devices, and/or domains. 

G.13: It is recommended that an appendix be provided with each phr 
specification that is targeted for local use Within a domain 

"yS^fSLflSSK f ° r m selection f °r **** which a™ forwarded 
into a peer domain which does not support the PHB group. 
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?oeci ; fi^Hnn r wh? m h e ^ ed -5 hat an appendix be provided with each pub 
S?STi?E^h^« h « COnS1 2 erS i the - 1m e afct of tne Proposed PHB group on 
allow for n^cf, r hi laye i: Protocols, under some circumstances PH6s may 
allow for possible changes to higher-layer protocols which mav 
increase or decrease the utility of theproposed ph! g7oup. V 

f D eci ; fi?atinn r wh°r me rn^ tha ^ an a Ppendix be provided with each phb 
trsuDDo?r?h/?n^H^°K m K nd - map P nQS t0 1 ink-layer QoS mechanisms 
switched liJk l^Clr de ? h be ^ avl0 '"- 0f ^ he P ? B acr °ss a shared-medium or 
switcned link-layer. The determination of the most aDDroDriate 

SSy'SctSTSdN^ TV ] i nk - la y er 2° s JechSiL^XiSInt on 
S2?ifi2?Sn^hn„?H^r de * the s S2 pe of this document; however, the 
speciri cation should attempt to offer some guidance. 

4. Interoperability with Non-Differentiated Services-Compliant Nodes 
we define a non-differentiated services-compliant node (non-DS- 
spTc fied in d ?DSP?ELST a n n3% Wh H Ch d ° eS "°t interpret the (n DS field as 
standardiUd pSrc f«?*k nd/o ^ does not implement some or all of the 
T 5 H n ( L th0Se J^ use Wlthin I Particular DS domain). 
H»ifn2 ^ i *° the capabilities or configuration of the node we 

wSHk 6 - 3 n 1egaCy node as a fecial case of a non-DS-compli ant node 
defined^nTRS?79i IPV ^r P ili C f den h e cl assifi cation and'fKrdinJas 
rSmllSni ' R 5 C1812 ]. but which is otherwise not DS- 

rnS5li?M; K Th - Precedence values in the IPv4 TOS octet are 
?5™K ^L ln h entl ° n V th t !2 e Class selector Codepoints defined in 
rRFC791 ] RPr?«i5i e , Pre i edenCe fo ™arding behaviors -defined in 
ilS ■rflt-SfS comply with the Class Selector phb Requirements 
and a D^rnl ? a n? SFI ^ LD ^ u k ey distinction between a^egacy node . 

intero?S H?2 t J n? d ^ 1S ^ hat the 1egacy n °de may or may not- 
?,^|rpret bits 3-6 of the TOS octet as defined in [RFC1349] (the 
DTR C .bits); in practice it will not interpret these bit as 

aefinedln'fRFCl'JpV 0 ; ^ &5SUme , that the u " of "heTOS Markings 
and wh?rh a S SJ 4 ? 3 15 deprecated. Nodes which are non-DS-compl.iant 

behaviors for 5Si e ISS a ^C odes may exnibit ^predictable forwarding 
Denaviors tor packets with non-zero DS codepoints. 
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Differentiated services depend on the resource allocation mechanisms 
provided by per-hop behavior implementations in nodes. The quality 
or statistical assurance level of a service may break down in the 
event that traffic transits a non-DS-compliant node, or a non-DS- 
capable domain. 

we will examine two separate cases. The first case concerns the use 
of non-DS-compliant nodes within a DS domain. Note that PHB 
forwarding is primarily useful for allocating scarce node and link 
resources in a controlled manner. On high-speed, lightly loaded 
links, the worst-case packet delay, jitter, and loss may be 
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negligible, and the use of a non-DS-compliant node on the upstream 
end of such a link may not result in service degradation. In more 
realistic circumstances, the lack of PHB forwarding in a node may 
make it impossible to offer low-delay, low-loss, or provisioned 
bandwidth services across paths which traverse the node. However, 
use of a legacy node may be an acceptable alternative, assuming that 
the DS domain restricts itself to using only the Class Selector, 
Codepoints defined in [DSFIELD] , and assuming that the particular 
precedence implementation in the legacy node provides forwarding 
behaviors which are compatible with the services offered along paths 
which traverse that node. Note that it is important to restrict the 
codepoints in use to the class Selector Codepoints, since the legacy 
node may or may not interpret bits 3-5 in accordance with lkfciiw yj , 
thereby resulting in unpredictable forwarding results. 

The second case concerns the behavior of services which traverse 
non-DS-capab-le domains, we assume for the sake of argument that a 
non-DS-capable domain does not deploy traffic conditioning functions 
on domain boundary nodes; therefore, even in the event that the 
domain consists of legacy or DS-compliant interior nodes, the lack or 
traffic enforcement at the boundaries will limit the ability to 
consistently deliver some types of services across the domain. A ds 
domain and a non-DS-capable domain may negotiate an agreement which 
governs how egress traffic from the DS-domain should be marked betore 
entry into the non-DS-capable domain. This agreement might be 
monitored for compliance by traffic sampling instead of by rigorous 
traffic conditioning. Alternatively, where there is knowledge that 
the non-DS-capable domain consists of legacy nodes, the upstream DS 
domain may opportunistically re-mark differentiated services trarric 
to one or more of the Class Selector Codepoints. Where there is no 
knowledge of the traffic management capabilities of the downstream 
domain, and no agreement in place, a DS domain egress node may choose 
to re-mark DS codepoints to zero, under the assumption that the non- 
DS-capable domain will treat the traffic uniformly with best-effort 
service. 

in the event that a non-DS-capable domain peers with a DS domain,, 
traffic flowing from the non-DS-capable domain should be conditioned 
at the DS ingress node of the DS domain according to the appropriate 
SLA or policy. 

5. Multicast Considerations 

use of differentiated services by multicast traffic introduces a 
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! n? t c D th doma .! n at an inaress node ma y simultaneously take 
Sacke? reSl?^r?Sn 0U9 ?n S ^ se 9 men £ s of the domain due to multicast 
pacKet replication, in this way they consume more network resources 
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S a ?"Cl S$f t packets, where multicast group membership is dynamic, 

IVt Jl hi rlL}° B r £ dlc V l ? advance the amount -of network resources 
that may be consumed by multicast traffic originating from an 

SnSfSTn!I t R r ShS r ^ Particular group., a consequence of ?his 
uncertainty is that it may be difficult to provide quantitative 
service guarantees to multicast senders.. Further? it may be 
n f£$$ s * r y t0 re serve codepoints and PHBs for exclusive use by unicast 
traffic, to provide resource isolation from multicast traffic. 

JackllTHiinn 6 ,^,^ ? e1ection °J the DS codepoint for a multicast 
£hf nc arriving at a DS ingress node. Because that packet may exit 
d5wn?trS a nL a - mul ^P le DS ^ress nodes which peer with multiple 
;cnnf^ e | m domain S! the DS codepoint used should not result in the 
■Ci2l«S™°«* a SerV1?e f rom a downs tream DS domain which is in 
ronnffinlr c a J 6er Z n9 SLA -- When establishing classifier and traffic 
receiv inn I XS™*.?\ D 5 lngreSS n ° de . for an aggregate of traffic 
h~?,tVZ 9 I differentiated service which spans across the egress 
??aSs?t y doL^^^nS ^,a h n • the . identity of the adjacent downstream 
transit domain and the specifics of the corresponding peering SLA can 

ooliVv'anl^hP^i-^^^^T 10 " decision CsSbject 9 tS S 
nplr^L ne .^ability of the routing infrastructure), in this way 
peering SLAs with downstream DS domains can be partially enforced at 

?rIffircond?H^fnn P H tr ^ am d0ma i n ' reducin9 th " classified and 
domain f ? burden at the egress node of the upstream 

Sll?- HnlM S .u 0t S0 ^V- y Performed in the case of multicast 
Sli rh^ ,? 6 Possibility of dynamic group membership. The ' ' 
imnarJpH ^ tne service guarantees for unicast traffic may be 
seSaSp'^PHn^irf f addressing this problem is to establish a 
Da??i-rul%r «r n 9. SLA for . mul ti cast traffic, and to either utilize a 
the necelLrv rlL C JP P °l" tS for mul ticast packets, or to implement 
the SI tarl2 nlH e r^ Cat1 °V nd traffic. conditioning mechanisms in 
5£ e f ?? r e ? re ss "odes to provide preferential isolation for unicast 
Sain? confo rmance with the peering SLA with the downstream 

6. Security and Tunneling Considerations 

diffprpnS^oH d c reS - es security issues raised by the introduction of 

T/rlict V4ltt. SerV l Ce l' P r ] m arily the potential for denial-of- 

un^hnrf^w^ 5 ' J- d } he re1at ed potential for theft of service by 

riifflrZnl* e i traffic (Sec. 6.1). in addition, the~operation of 

w th ?P^r a Jnp f? rV1 S eS 1n the presence of IPsec and its interaction 

?eaSiremISt a r^ S °A d li CUS ^ d CSec.6.2), as well as auditing 

the lit of hJh e ™J; 3) ^ ThlS sect ™ n considers issues introduced by 

tne use or both IPsec and non-iPsec tunnels. 
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6.1 Theft and Denial of Service 

The primary goal of differentiated services is to allow different 
levels of service to be provided for traffic streams on a common 
network infrastructure. A variety of resource management techniques 
may be used to achieve this, but the end result will be that some 
packets receive different (e.g., better) service than others. The 
mapping of network traffic to the specific behaviors that result in 
different (e.g., better or worse) service is indicated primarily by 
the DS field, and hence an adversary may be able to obtain better- 
service by modifying the DS field to codepoints indicating behaviors 
used for enhanced services or by injecting packets with the DS field 
set to such codepoints. Taken to its limits, this theft of service 
becomes a denial -of -service attack when the modified. or injected 
traffic depletes the resources available to forward it and other 
- traffic streams. The defense against such theft- and denial -crT-^ 
service attacks consists of the combination of traffic conditioning 
at DS boundary nodes along with security and integrity of the network 
infrastructure within a DS domain. 

as described in Sec. 2,^-DS ingress nodes must condition all traffic 
entering a DS domain to ensure that it has acceptable DS codepoints. 
This means that the codepoints must conform to the applicable TCAts; 
and the domain's service provisioning policy. Hence, the ingress 
nodes are the primary line of defense against theft- and denial-ot- 
service attacks based on modified DS codepoints (e.g., codepoints to 
which the traffic is not entitled), as success of any such attack 
constitutes a violation of the applicable TCA(s) and/or service 
provisioning policy. An important instance of an ingress node is 
that any traffic-originating node in a DS domain is the ingress node 
for that traffic, and must ensure that all originated traffic carries 
acceptable DS codepoints. 

Both a domain's service provisioning policy and TCAs may require the 
ingress nodes to change the DS codepoint on some entering packets 
(e.g., an ingress router may set the DS codepoint of a customer s 
' traffic in accordance with the appropriate SLA). Ingress nodes must 
condition all other inbound traffic to ensure that the DS codepoints 
are acceptable; packets found to have unacceptable codepoints must 
either be discarded or must have their DS codepoints modified to 
acceptable values ^bef ore being forwarded. For example, an ingress 
node receiving traffic from a domain with which no enhanced service 
agreement exists may reset the DS codepoint to the Default PHB 
codepoint [DSFIELD] . Traffic authentication may be required to 
validate the use of some DS codepoints (e.g., those corresponding to 
enhanced services), and such authentication may be performed by 
technical means (e.g., iPsec) and/or non-technical means (e.g., the 
"inbound link is known to be connected to exactly one customer site).' 
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An inter-domain agreement may reduce or eliminate the need for 
ingress node traffic conditioning by making the upstream domain 
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?odeioi^s C ?Sn^lT/^ Sp ^ Si ^ e f °r 4 ensuHn 9 that traffic has DS 
ln ts acceptable to the downstream domain, in this case the 
IZ 9 ,1a S n °tt may "I 11 Perform redundant traffic Eonditioninq' checks 
to reduce the dependence on the upstream domain (eg such checks 
d^n^V" 6 ^ 0 ^ 56 ™ 1 '" atta ^s from propagat ng' across the 

is no? SlfniTin ill SUCh 3 W t^' 15 b ' caSs ^ the^pscrlL domain 
J pn n ? ™I f y lln 9 its responsibilities, that failure is an audi table 

packet wal fSSSS? ?hfi 109 ent ^ sh °^d include the datl/i 2 the 
pacKer was received, the source and destination IP addresses and thp 

froS°2S 1 5edS t n2S S S Ep* f ^l U 7- ^ P^ctice .Ihe'limited^aiS 
rrom sucn cnecks need to be weighed against their potential 

Interior nodes in a DS domain may rely on the DS field to associate 

oSe?arinn nf rh! Ac ^ ny node d01ng so depends on the correct 
operation of the DS domain to prevent the arrival of traffic with 

SriS!? t S 1 !L.?LX de P 0 l nts ■ R ° bus tness concerns dictate" that ihe 
faT ure ?e a " ?S s K t 5f U IIS Cep P lbl 5 DS cod epoints <Wnot causl the 
r^DonHhi; 9 ^ «I - 1 0f network n ? d es. Interior nodes are not 
ind?Sirf7i^cf?^ enf ST n9 the service provisioning policy (or 
before u?ino^hL and T henC ^ are 2 0t squired to check DS codepoints 
rn!3^«nl22 t .' Inte nor nodes may perform some traffic 
S2? VrZ l»L r heC 4 2 n DS c °depoints (e.g., check for DS codepoints 
security Snri rnhPfJ f ° r Y aff " c on a specific link) to improve 
IIIJa y ^ nd r ° bus tness (e.g., resistance to theft-of-service attacks 
check is an XfiEttl- nations).. Any detected failure of such a 
includP %hp HaJl/S Te !u ent and the generated audit log entry should 
include the date/time the packet was received, the source and 

ftlllS^-VErlST??"?* a ? d ^ e , DS ? 0deD0i ^ thlt^ed^he 
we qhed"aaains fhlir'nS 6 l™] ted i ains fr ™ such checks need to be 
what if SJ rhSrtl r P° ten tial performance impact in determining 
wnat, it any, checks to perform at interior nodes. 

cCdepoints h or ^fWr^nSS?"'!* S ^ Cured a9ainst ?°difi cation of DS 
bounds rv lint L I C section by adversaries should be treated as a 
as if i? lire ent^rin^^ arrivin 9 traffic on that link is treated 
tlrnUll !!oi e entering the domain at an ingress node). Local 
cf^ ty A 2 p1 - cy Provides the definition of "adequately secured " and 
consequences'of^^ a determination tSat th£ risks and ^ 

no? i2s?ifv s =HH^ dep °^ nt mod l ^cation and/or traffic injection do 
not justify any additional security measures for a link Link 

me'anrs^as^unnP?,^ ? a P^i«l acce« controls "and/or "software 
means sucn as tunnels that ensure packet integrity. 
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6.2 iPsec and Tunneling Interactions 

heIder"! C Ds r fi^^ AH b does not delude the IP 

else of tunnl indl an y. of J* 5 cryptographic calculations (in the 
C ? S T i unnel mode, it is the outer IP header's DS field that u nnr 

no nC effIct^n^ e ?sec-s d ln f d C r a n i0n H° f the - DS f L. efd by a neSiSr^SdeM? 
IPsir?n?eCri^ rnprk ?n"f^ end secunt y> because it cannot cause any 
orovidP Jnv HoL^f i t<? fai1 ' ^ s a consequence, IPsec does not 
provide any defense against an adversary's modification of the DS 
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field (i.e., a man-in-the-middle attack), as the adversary s 
modification will also have no effect on IPsec' s end : to-end security, 
in some environments, the ability to modify the DS. field without 
. affecting iPsec integrity checks may constitute a covert channel; it 
it is necessary to eliminate such a channel or reduce its bandwidth, 
the DS domains should be configured so that the required processing 
(e.g., set all DS fields on sensitive traffic to a single value) can 
be performed at DS egress nodes where traffic exits higher security 
domains. 

IPsec's tunnel mode provides security for the encapsulated IP 
header's DS field. A tunnel mode IPsec packet contains two IP 
headers: an outer header supplied by the tunnel ingress node and an 
encapsulated inner header supplied by the original source of the 
packet. When an IPsec tunnel is hosted (in whole or in part) on a 
differentiated services network, the intermediate network nodes 
operate on the DS field in the outer header. At the tunnel egress 
node, IPsec processing includes stripping the outer header and 
forwarding the packet- (if required) using the inner header . It 
the^ inner IP header has not been processed by a DS ingress node for 
the tunnel egress node's DS domain, the tunnel egress node is the DS 
ingress node for traffic exiting the tunnel, and hence must carry out 
the corresponding traffic conditioning responsibilities (see Sec. 
6.1). If the IPsec processing includes a sufficiently strong 
cryptographic integrity check of the encapsulated packet (where 
sufficiency is determined by local security policy) , the. tunnel 
egress node can safely assume that the DS field in the inner header 
has the same value as it had at the tunnel ingress node. This allows 
a tunnel egress node in the same DS domain as the tunnel ingress 
node, to safely treat a packet passing such an integrity check as it 
it had arrived from another node within the same DS domain, omitting 
the DS ingress node traffic conditioning that would otherwise be 
required. An important consequence is that otherwise insecure links 
internal to a DS domain can be secured by a sufficiently strong IPsec 
tunnel . 

This analysis and its implications apply to any tunneling protocol 
that performs integrity checks, but the level of assurance of the 
inner header's DS field depends on the strength of the integrity 
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check performed by the tunneling protocol. In the absence of 
sufficient assurance for a tunnel that may transit nodes outside the 
current DS domain (or is otherwise vulnerable), the encapsulated 
packet must be treated as if it had arrived at a DS ingress node from 
_CLUtside the domain. 

The IPsec protocol currently requires that the inner header's DS 
field not be changed by IPsec decapsulation processing at a tunnel 
egress node. This ensures that an adversary's modifications to the 
DS field cannot be used to launch theft- or deni al -of-servi ce attacks 
across an IPsec tunnel endpoint, as any such modifications will be 
discarded at the tunnel endpoint. This document makes no change to 
that IPsec requirement. 

If the IPsec specifications are modified in the future to permit a 
tunnel egress node to modify the DS field in an inner IP header. based 

Page 27 



346849.1 

on the DS field value in the outer header (e.g., copying part or all 
of the outer DS field to the inner DS field), then additional 
considerations would apply. For a tunnel contained entirely within a 
single DS domain and for which the links are adequately secured 
against modifications of the outer DS field, the only limits on inner 
DS field modifi cations would be. those imposed by the domain's service 
provisioning policy. Otherwise, the tunnel egress node performing 
such modifications would be acting as a D~S ingress node for traffic 
exiting the tunnel and must carry out the traffic conditioning 
responsibilities of an ingress node, including defense against theft - 
and- denial -of-service attacks (See Sec. 6.1). If the tunnel enters 
the DS domain at a node different from the tunnel egress node, the 
tunnel egress node may depend on the upstream DS ingress node having 
ensured that the outer DS field values are acceptable. Even in this 
case, there are some checks that can only be performed by the tunnel 
egress node (e.g., a consistency check between the inner and outer DS 
codepoints for an encrypted tunnel) . Any detected failure of such a 
check. is an auditable event and the generated audit log entry should 
include the date/time the packet was received, the source and 
destination IP addresses, and the DS codepoint that tos' unacceptable. 

An iPsec tunnel can be viewed in at least two different ways from an 
architectural perspective, if the tunnel is viewed as a logical 
single hop "virtual wire", the actions of intermediate nodes in 
forwarding the tunneled traffic should not be visible beyond the ends 
of the tunnel and hence the DS field should not be modified as part 
of decapsulation processing, in contrast, if the tunnel is viewed as 
a multi-hop participant in forwarding traffic, then modification of 
the DS field as part of tunnel decapsulation processing may be 
desirable. A specific example of the latter situation occurs when a 
tunnel terminates at an interior node of a DS domain at which the 
domain administrator does not wish to deploy traffic conditioning 
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logic (e.g., to simplify traffic management). This could be 
supported by using the DS codepoint in the outer IP header (which was 
subject to traffic conditioning at the DS ingress node) to reset the 
DS codepoint in the inner IP header, effectively moving DS ingress 
traffic conditioning responsibilities from the IPsec tunnel egress 
node to the appropriate upstream DS ingress node (which must already 
perform that function for unencapsulated traffic). 

6.3 Auditing 

Not all systems that support differentiated services will implement 
auditing. However, if differentiated services support is 
incorporated into a system that supports auditing, then the 
differentiated services implementation should also support auditing. 
If such support is present the implementation must "allow a system 
administrator to enable or disable auditing for differentiated 
services as a whole, and may allow such auditing to be enabled or 
disabled in part. 

For the most part, the granularity of auditing is a local matter. 
However, several auditable events are identified in this document and 
for each of these events a minimum set of information that should be 
included in an audit log is defined. Additional information (e.g., 
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packets related to the one that triggered the audi table event) may 
also be included in the audit log for each of these events, and 
additional events, not explicitly called out in this specification, 
also may result in audit log entries. There is no requirement tor 
the receiver to transmit any message to the purported sender in 
response to the detection of an audi table event, because of the 
potential to induce denial of service via such action. 

7. Acknowledgements 

This document has benefitted from earlier drafts by Steven Blake, 
David Clark, Ed Ellesson, Paul Ferguson, Duha Heinanen, van. 3acobson, 
Kalevi Kilkki, "Kathleen Nichols, waiter Weiss, John wroclawski, and 
Lixia Zhang. 

The authors would like to acknowledge the following individuals for 
their helpful comments and suggestions: Kathleen Nichols, Brian 
Carpenter, Konstantinos DovroTis, Shivkumar Kalyana, wu-chang Feng, 
Marty Borden, Yoram Bernet, Ronald Bonica, James Binder, Bone 
OhVman, Alessio Casati , Scott Brim, Curtis yillamizar, Hamid Ould- 
Brahi, Andrew Smith, John Renwick, Werner Almesberger, Alan.O Nei II , 
James Fu, and Bob Braden. 



Blake, et. al. Informational [Page 32] 

RFC 2475 Architecture for Differentiated Services December 1998 



8. References 



[802. lp] 



ISO/IEC Final CD 15802-3 information technology - Tele- 
communications and information exchange between systems - 
Local and metropolitan area networks - Common 




[AH] 



Kent, S. and R. Atkinson, "IP Authentication Header", RFC 
2402, November. 1998. 



[ATM] 



ATM Traffic Management Specification version 4.0 <af-tm- 
0056. 000>, ATM Forum, April 1996. 



[Bernet] 



Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, K. 
Nichols, and M. Speer, "A Framework for. use of RSVP wit 
Diff-serv Networks", work in Progress. 



[DSFIELD] 



Nichols, K . , Blake, s., Baker, F. and D. Black, 
"Definition of the Differentiated Services Fiel 
Field) in the IPv4 and IPv6 Headers", RFC 2474, 
1998. 




[EXPLICIT] 



D. Clark and w. Fang, "Explicit Allocation of Best Effort 
Packet Delivery Service", IEEE/ACM Trans, on Networking, 
vol. 6. no. 4, August 1998, pp. 362-373. 



[ESP] 



Kent, S. and R . Atkinson, "IP Encapsulating security 
Payload (ESP)", RFC 2406, November 1998. 



Page 29 



346849.1 

[FRELAY] ANSI Tlsi, "dssi Core Aspects of Frame Rely", March 1990. 

[RFC791] Postel, 3 . , Editor, "Internet Protocol", STD 5, RFC 791, 
September 1981. 

[RFC1349] Almquist, P., "Type of Service in the Internet Protocol 
Suite", RFC 1349, Duly 1992. 

[RFC1633] Braden, R. , Clark, D. and S. Shenker, "Integrated 

Services in the Internet Architecture: An Overview", RFC 
1633, July 1994. 

[RFC1812] Baker, F. , Editor, "Requirements for IP Version 4 
Routers", RFC 1812, June 1995. 

[RSVP] Braden, B., Zhang, l., Berson S., Herzog, S. and S. 

Jamin, "Resource Reservation Protocol (RSVP) -- version 1 
Functional Specification", RFC 2205, September 1997. 



Informational 



Blake, et. al . 

D 

RFC 2475 Architecture for Differentiated Services 



[Page 33] 
December 1998 



[2BIT] K. Nichols, v. Jacobson, and L. Zhang, "A Two-bit 

Differentiated Services Architecture for the Internet", 
ftp://ftp.ee.lbl.gov/papers/dsarch.pdf, November 1997. 

[TR] ISO/IEC 8802-5 Information technology - 

Telecommunications and information exchange "between 
systems - Local and metropolitan area networks - Common 
specifications - Part 5: Token Ring Access Method and 
Physical Layer Specifications, (also ANSI/IEEE Std 802.5- 
1995), 1995. 

Authors 1 Addresses 

Steven Blake 

Torrent Networking Technologies 
3000 Aerial Center, Suite 140 
Morrisville, NC 27560 

Phone: +1-919-468-8466 x232 
EMail: slblake@torrentnet.com 



David L. Black 
EMC Corporation 
35 Parkwood Drive 
Hopkinton, MA 01748 

Phone: +1-508-435-1000 x76140 
EMai 1 : bl ack_davi d@emc . com 



Mark A. Carlson 

Sun Microsystems, Inc. 

2990 Center Green Court South 

Boulder, CO 80301 



Phone: +1-303-448-0048 xll5 

Page 30 



EMail: mark.carlson@sun.com 



346849.1 



Elwyn Davies 
Nortel UK 
London Road 

Harlow,. Essex CM17 9na, uk 

Phone: +44-1279-405498 
EMail: elwynd@nortel.co.uk 



Blake, et. al . Informational [Page 34] 

RFC 2475 Architecture for Differentiated Services December 1998 



zKeng wang 

Bell Labs Lucent Technologies 
101 Crawfords Corner Road 
Holmdel, ND 07733 

EMail: zhwang@bell-labs.com 



Walter Weiss 

Lucent Technologies 

300 Baker Avenue, Suite 100 

Concord, MA 01742-2168 

EMail: .wweiss@lucent.com 



Page 31 



346849.1 



Blake, et. al . Informational [Page 35] 

RFC 2475 Architecture for Differentiated Services December 1998 

Full Copyright Statement 

Copyright (C) The Internet Society (1998). All Rights Reserved. 

This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind provided that the above copyright notice and this paragraph are 
included 911 all such copies and derivative- works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
English ° r aS requ " ired t0 translate it into languages other than 

The limited permissions granted above are perpetual and will not be 
revoked by the internet Society or its successors or assigns. 

I^ s T ^ c " ment and , th e information contained herein is provided on an 

-r*L ™„5 aS1S and ™ E INTERN ET SOCIETY AND THE INTERNET ENGINEERING 
If£ „E2 RCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
F^T * 0T LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
"I**?* WILL N0T INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 



Page 32 



Blake, et. al . 

D 



346849J. 
Informational 



[Page 



Page 33 



THIS PAGE BLANK (uspto) 



